NetBSD/alpha Frequently Asked Questions

Here are some frequently asked questions (and frequently given answers!) about NetBSD/alpha.

Can NetBSD/alpha be run on systems with only NT firmware?

No. NetBSD/alpha requires the SRM Console firmware (used by OSF/1 and OpenVMS) to function. There are two main reasons for this: the console software is what's resposible for loading the operating system's primary bootstrap program, and the NT firmware's method of doing this is undocumented; and the firmware provides the PALcode for the system, which handles low-level memory management and interrupt handling details on a system-specific basis.

Other systems, such as the Alpha port of Linux, apparently do support systems which only have NT firmware. Because of the difficulty of making this work, it is unlikely to happen for NetBSD/alpha in the near future unless someone with a vested interest in having it work actually writes the code to do it.

What video cards are supported by X11?

At this time, only the ZLXp-E1 frame buffer is supported by the NetBSD/alpha X11 server. Hopefully that will change in the near future.

Can NetBSD/alpha boot diskless?

In NetBSD 1.2 or earlier:
Sort of. The kernel supports booting with NFS root and swap partitions, found via bootparam requests. Unfortunately, there's no network boot loader. In other words, you have to put a NetBSD kernel on a Digital UNIX disk and boot the kernel from the disk (with a command like boot -fi "kernelname").
After NetBSD 1.2:
Yes. Starting after the NetBSD 1.2 release, NetBSD/alpha supports diskless booting with bootp. You must have a recent version of the SRM console firmware for this to work. You'll need to configure a bootp server to provide the firmware and boot blocks with the correct information, as well as configuring a bootparam server and the NFS root and swap devices as described in the NetBSD diskless(8) manual page. Complete diskless booting documentation has not yet been written.

If you try to set up a Digital UNIX (formerly DEC OSF/1) system as an NFS server containing NetBSD diskless root partitions, you'll run into a problem: Digital UNIX does not properly handle NetBSD device nodes. Apparently, to ease the transition from 16-bit to 32-bit device nodes, Digital added run-time conversion code to convert from the old device node format to the new format. Unfortunately, this causes the device nodes as seen by a diskless NetBSD to be garbage. The only solutions to this are binary or source modifications to the Digital UNIX kernel, so, for most users, the easiest solution is to simply not use a Digital UNIX system as the server for NetBSD diskless clients.

How do I make a hard disk bootable?

To make a hard disk bootable, you have to copy the NetBSD/alpha second-stage bootstrap, /usr/mdec/boot, to the root directory of the file system on the disk's a partition and use the instalboot(8) program to install the first-stage bootstrap. Using sd1 as an example:

    # mount the file system
    mount /dev/sd1a /mnt

    # install the bootstrap programs
    cp /usr/mdec/boot /mnt
    sync
    sync
    ./installboot /mnt/boot /usr/mdec/bootxx /dev/sd1a

You must be in single-user mode to do this, or have the kernel security mode set to 0 if you are in multi-user mode. If you're making an already-mounted disk bootable or reinstalling boot blocks on your root disk, you will not have to (and/or may not be able to) remount it, so this example may not be correct for all situations.

Note that NetBSD/alpha can only boot from disks' a partitions, and that the a partition of a bootable disk must start at the beginning of the disk. A bootable disk's a partition must also contain a NetBSD/alpha kernel (otherwise, you won't have anything to boot!).

In addition to working for hard disks, this procedure also works for SCSI removable-media devices (such as Zip and Jaz drives) that contain BSD disklabels.

Why does my Multia/UDB find bogus PCI devices at boot time?

Some Multia/UDB systems, when booted using a serial console, print boot messages like:
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 0 function 0 not configured
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 1 function 0 not configured
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 2 function 0 not configured
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 3 function 0 not configured
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 4 function 0 not configured
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2,
revision 0x0d) at pci0 dev 5 function 0 not configured
and incorrectly recognize the TGA frame buffer as a PCI VGA frame buffer. This is a firmware bug, but unfortunately no official version of the Multia/UDB firmware released by DEC fixes it.

Chris Demetriou <cgd@netbsd.org> has a firmware update floppy image which contains firmware that fixes this problem. Get in touch with him if you need it.


NetBSD Alpha port page
NetBSD Home Page
www@NetBSD.ORG
$NetBSD: faq.html,v 1.6 1996/11/08 17:19:27 cgd Exp $
Copyright (c) 1996 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.